. 1 . 

Title : Rekeying in Secure IViobtie Multicast Communications 

Description 

Field of the invention 

5 This invention relates to rekeying in secure mobile multicast communications 

and, more specifically to inter-area rekeying of encryption keys. 

Background of the invention 

The emergence of new Internet applications such as video-conferencing, 
e-learntng and many other applications which are based on group communications 

10 experience new challenges such as support of user mobility. A new type of 
Internet solution is being specified to allow users to communicate with multiple 
remote hosts while moving in the Internet. In the perspective of deploying 
multiparty-based applications, the Internet Engineering Task Force (IETF) has 
defined the IP multicast model [S. Peering, "Host Extension for IP Multicasting", 

15 Internet RFC 1112, August 1989]. This model allows any user to send Data Traffic 
in a single copy of its message to a group of hosts knowing only their group 
address, or more exactly their multicast address: members join the group by 
subscription without the sender needing (nor being able) to use the individual 
group members' unicast addresses. The sender's message is then optimally 

20 duplicated by multicast routers on the path towards the receivers. 

Unfortunately, the IP Multicast model was originally specified without security 
support- This issue remains an obstacle for a broader deployment of IP multicast, 

especiayy for secjr^n sensitive applfcations such as Pay-Per-View, private 
conferences and miytary- commonications, for exarnple, where data confidentiality 
25 in a dynamic membership context is necessary. Furthermore, the mobility of users 
complicates the fP multicast security problem. 

While general aspects of the multicast security issues [for example T, 
Hordiono and B. Weis, " The Multicast security (MSEC) Architecture^ internet 
draft, draft-ietf-msec-arch-04-txt, November 2003] and group encryption key 



-2- 

management issues [for example Mark Baugher and al., 'The Group Domain of 
Interpretation", internet RFC 3574, July 2003] have been broadly addressed 
through multiple worths and studies, the impact of member's mobility has not been 
Widely considered. The expression Intra-group mobility' is used herein to refer to 
5 movement of member between administrative areas (Inter-autonomous-system 
mobility'), without leaving or joining a group. The group is normally defined by the 
multicast address to which the member has subscribed. However, in some 
circumstances, it would be desirable for a mobile member to remain part of a 
group defined by the Traffic Encryption Key while changing multicast address. 

10 Such mobility complicates the IP multicast security problem. In fact, inter- 

autonomous-systemmobility confuses the group membership dynamism since 
mobile members not only wish to join or leave the multicast group, but may also 
wish to move within the group between networks or areas white remaining (from a 
group membership viewpoint) in the secure session. However, member's 

15 movement between networks or areas may compromise data secrecy. This would 
normally require expensive rekeying (the generation of new keying materials) for 
the existing members in order to ensure data secrecy (Forward and Backward 
Secrecies). Such a constraint is due to the fact that the underlying group key 
management service was only designed for stationary members [M. Baugher, R, 

20 Canetti, L Doneti, and F. Lindhotm, ''Group Key Management Architecture", 
Internet draft, draft-ietf-msec-gkmarch-06.txt, September 2003]. 

The Multicast Security (msec) Working Group of the Internet Engineering 
Task Force (IETF) specifies a common architecture for secure multicast 
communications [T. Hordjono and Weis, "The Multicast security (MSEC) 

25 Architectures internet draft, draft-fetf-msec-arch-04.txt. November 2003]. This 
architecture defines a security entity used for delivery and management of 
cryptographic keys in secure groups. Such an entity is called the Group C-ontrofler 
Key Server (GCKS)» The aigorithrns that manage Ilia distribution, rekeying 
(^updating'), and revocation of the group keys are known as group key 

30 management protocols. The challenge of any key management protocol is to 
generate and distribute nev¥ keys such that the data remains secure whiie the 
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overall impact on system performance is minimized. There are two basic designs 
of group key management model: a centralized design and a distributed design* 

In the centralized design, there is a single GCKS that manages the keying 
material for ail the group members. 

5 In a distributed architecture the GCKS entity interacts securely with other 

GCKS entities to provide more scalable group management services, and hence 
to avoid signaling overhead and system bottleneck in the case of a large number 
of group members, which are more tikely in the case of a centralized architecture. 
The manager of the entire group - the domain - is called the Domain GCKS. The 

10 domain is divided into administrative regions called areas. The area may be 
constructed on either a physical or a logical basis. For example, an area may 
represent a Corporate Network, or may contain a set of users that belong to a 
common logical group or coatition, independently of their physical location. Each 
area is managed by an area GCKS, a 1ocai GCKS\ The present invention relates 

1 5 to the distributed architecture. 

In order to ensure the confidentiality of multicast application data, the Domain 
GCKS generates and distributes to all group members a common key called a 
Traffic Encryption Key (TEK). This key is used by the multicast source to encrypt 
data traffic, and by receivers to decrypt source's data. In a distributed scheme, 

20 when the Domain GCKS generates the data key (TEK), it multicasts it securely to 
each area's local Group Controller Key Server (GCKS). The local GCKS is 
responsible for distributing the TEK to members within its area in a secure fashion 
using a specific key called: Key Encryption Key (KEK). These keys are used by the 
local GCKS to encrypt the TEK and subsequent KEK versions (local rekeying). 

26 The means by ^hrch the local GCKS distributes keys in a secure fashion may 
mclude a unicast or multicast secure clianneL a logicai hierarchy of keys or an 
extension of the server hierarchy. This framework is depicted in Figure 1 of the 
accompanying drawings- 

The group is dynamic, so that when a new member joins the group, the TEK 
30 must be changed to ensure that the newfy joining member cannot decrypt previous 
comnnynteations; this requirement is called Backv^ard Secrecy, In the same way, 
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whenever a member leaves the group session, the TEK must be changed - 
rekeyed - to ensure that the leaving member cannot decrypt further 
communications using the TEK it held before leaving the session; such a 
requirement is called Forward Secrecy. In addition, during a secure multicast 
5 session, keys will have a predetermined lifetime and will be periodically refreshed 
according to particular intervals- This ensures that no keying material remains valid 
for more than a fixed period of time. 

In more detail, when a new member joins the group through a given area it 
sends the local GCKS a signalling message to request the Group Traffic 

10 Encryption Key (TEK) as well as the local KEK, The local GCKS then creates and 
multicasts a new KEK to all the existing members of its area encrypted with the 
previous KEK. The new KEK is also unicast to the new member using a secure 
channel established using suitable mechanisms such as those based on a shared 
key or member's public key. Once the new KEK is distributed in the relevant area, 

15 the Domain GCKS multicasts the new TEK to all local GCKSs and then each local 
GCKS (GCKSb GCKSj and so on) fonA/ards the new TEK to group members in 
their respective areas in one multicast distribution using the respective KEKs 
(KEKi, KEKj and so on). The process of updating the keying material when a new 
member joins the group ensures backward secrecy. As a result the new member 

20 cannot have access to an unchanged KEK to decrypt the previous TEK that was 
encrypted with an unchanged KEK, and thus cannot obtain data transmitted prior 
to its arrival- 

When a member leaves the multicast group, all the valid keys it held just 
before leaving the session must be changed by notifying its local GCKS. In this 

25 case, the members local GCKS will create and distribute a new KEK to the 

remaining area members. The proposed solutions for Inter-area rekeying we will 
review here suggest using a unicast secure channel to distribute the new KEK to 
each remaining member, instead of multicasting, since for both scaiability and 
performance reasons, the GCKS does not have an encryption key shared only 

30 With all the remaining members (that is to say all except the teaving member), and 
hence the QCKS could not use multicast tc^ send the new KEK only to the 
remaining members. Once the new KEK is distributed, the Domain GCKS 
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generates and distributes a new TEK to all the local GCKSs. Each local GCKS 
then forwards securely the new TEK to all its area members using the KEK. This 
method ensures forward secrecy. That is, a leaving member cannot decrypt future 
group communications in any area because it does not have the required keying 
5 materials (i.e. the new TEK and the new KEK). 

In summary, the group key management service is required to ensure the 
following features in respect of ail group members, even for group members that 
move intra-group between different areas in the domain - inter-area mobility : 

• Confidentiality: Onfy group members can read the multicast traffic. 

1 0 ♦ Backward secrecy: Every time a new member joins the group, the Traffic 
Encryption Key (TEK) must be changed for all group members to ensure 
that the new member cannot decrypt previously transmitted data traffic. 

♦ Forward secrecy: When any group member leaves the multicast group, the 
TEK must be changed for the remaining group members to ensure that the 

1 5 leaving member cannot decrypt subsequent data traffic. 

The situation for intra-group inter-area mobility is illustrated in Figure 2, in 
which a current group member MM^ initially in the area managed by GCKSi moves 
intra-group to the area managed by GCKSj, a current group member MM]i initially 
in the area managed by GCKS| moves intra-group to the area managed by GCKSi, 
20 and a current group member MIV4kj initially in the area managed by GCKSk moves 
intra-group to the area managed by GCKSj. 

It will be appreciated that each area may contain one or more Autonomous 
Systems (ASs) such as Corporate Networks that may represent a distinct 
organization with its own physical network. The ASs may also be iimited by 

25 geogiraphicaf constraints. Problems have arisen with proposed mechanisms for 
rekeying, due to security policies, key latency and risks of traffic interruptions and 
over-frequent Inter-area signalfing. 

One known proposal, referred to as a Static Rekey (SR) approach is 

iflustrated m Figure 3 [C. Zhang and al=, ""Comparison of Inter-Area Rekeying 
30 Aigorithms for Secure Wireless Group Communications''. IFIP WG 7.3 
International Symposium on Computer Performance Modeling, Measurement and 



Evaluation, September 2000]. In this proposal, the local GCKSi maintains the KEKi 
unchanged when a mobile member MMij moves intra-group to a new area. That is, 
the mobile member MMij will continue receiving the KEKj originating from its 
GCKSj. To achieve this, the GCKSj may use inter-area multicast to distribute 
5 ufxiates of KEKj for members out of the area. OthenA/ise, it may use a fonwarding 
node, such as the Home Agent in the case of Mobile IP. 

This approach is straightforward and does not require the mobile member 
MMij to register with the new local GCKSj whenever it moves to a new areaj. In 
addition, movement of the member MMij between the two areas affects neither the 

10 members of the previous area nor those of the new one. However, the Static 
Rekey approach may not work in case where the mobile member moves to a 
network that belongs to a new administrative area where the security policy 
restricts the traffic and the interactions with foreign areas. This may be the case 
when the entire network consists of a coalition composed of loosely connected 

15 ASs (e.g., in cooperative military), for example, or when the keys are multicast to 
the members. Moreover, with the Static Rekey Approach the distribution of keying 
material to members MMjj out of their areas may suffer latencies or may even fail. 
Such problems are especiaify constraining in applications that depend on a rapid 
dissemination of secure information such as military operations, for example. 

20 In order to reduce both these latencies and inter-AS Signaling, new 

approaches have been defined proposing mapping the logical area structure 
directly onto the physical tofx>logy of the network. In addition, these approaches 
propose moving the key changes as close as possible to the members, shifting 
existing trust relationships to the current location of the mobile member to support 

25 future key exchange and efiminatrng the member's dependence on a distant 
security server. 

If the inter-area movement of the mobile member MM^j were simp!y 
considered as a leave from the old area GCKSi followed by a join to the new area 
GCKSj, this case would be assimilated to that of a member joining and/or leaving 
30 the group altogether. This wouSd introduce an interruption of data transmission as 
well as additional computations whenever the mobile member transfers between 
areas. In addition, new TEKs may be generated twice due to the movement of the 
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member MM^ if the Domain GCKS considers that the entering member is both a 
memt^r leaving and a member joining the group. 

Another known proposal, referred to as an Immediate Rekey (fR) approach is 
illustrated in Figure 4 [8. DeCleene, LDondeti, S« Griffin, T. Hardjono, D, Kiwior, J. 
5 Kurose, D. Towsley, S. Vasudevan, and 0. Zhang, ^'Secure Group 
Communications for Wireless Networks'', Proceedings of Mifitary Communications 
Conference, IEEE MILCOM, Communications for Network-Centric Operations: 
Creating the Information Force. Vienna, October 2001, pp. 113-117]. The 
Immediate Rekey algorithm defines new semantics that address member's 

10 moblHty, In fact, when a group member MMjj moves to a new area, it sends a 
signaling message to the previous GCKSi as well as the visited GCKS). The areas 
GCKSj and GCKS] then update their local KEKs. No TEK rekey is required since 
the member MMy proves its group membership to the new local GCKSj using 
specific information called credentials, for example in the manner described in S, 

15 Griffin, B, DeCleene, L Dondeti, R. Flynn, D, KIwior, and A. Olbert," Hierarchical 
Key Management for Mobile Multicast Members. Accordingly, the data 
transmission continues uninterrupted. 

This approach is simple from a key management point of view. In addition, it 
separates the case of intra-group mobile members from that of members entering 
20 or leaving the group by maintaining the TEK unchanged when a current group 
member moves between areas. However, it implies systematic rekeying of the 
local KEKs KEKi and KEKj for all group members within the areas affected by the 
handover of the mobile member MMy. Thus, the efficiency of this approach is 
seriously affected in the case of group members with a high inter-area mobility. 

25 Yet another known proposal, referred to as a First Entr/ Delayed ReK&y^- 

Periodic (FEDRP) approach is iHustrated m Rgurs 5 [C Zhang and aL, 
^'Comparison of inter-Area Rekeying Algorithms for Secure Wireless Group 
Communications^ IFiP WG 7.3 International Symposium on Computer 
Performance Modeling, Measurement and Evaluation, September 2000], The 

30 FEDRP approach is Ilka the IR approach in the use of semantics of transfer 
between areas. It enhances this approach, however, since no local rekeying 
occurs in the previous area. That is, when the member MMy moves intra-group 
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from areai to areaj, it sends one signalling message to GCKSi and one signalling 
message to GCKSj. GCKSj then adds the member MMy to a list of members that 
have left the area by intra-group mobility without leaving the group and still hold a 
valid area key KEKi for a limited period of time. This list is called an Extra Key 
5 Owner List (EKOL). It is reset when and if a member holding a valid area key 
KEKi, fn areai or visiting another area, leaves the group and when the timer of the 
validity period expires. In some cases, the mobile member MMjj may accumulate 
multiple KEKs that correspond to different areas it has been in. If the mobile 
member MMi| returns to an area it has previously visited, the local GCKS checks if 

10 this member is on the local EKOL list if this is the case, it wit! be removed from the 
list and no rekeying will be needed. In this case, the mobile member MMj| receives 
(optionally) the current KEKi using a secure channel However, if the member MMy 
is not present in the list, a new KEKj is generated and sent in one multicast 
distribution to current area members using the previous KEKi, and in a unicast 

1 5 transmission using a secure channel to the mobile member MMy. 

In order to ensure fonward secrecy, when a mobile member MMy visiting 
another area leaves the group session, all the KEKs it holds must be changed for 

all the group members holding those KEKs within the affected areas and, in 
addition, all the EKOL lists holding those KEKs are reset. The KEK that the 
20 member holds out of areai may also be changed under specific conditions related 
to EKOLi (especially expiration of the key validity period). 

The FEDRP approach improves significantly the inter-area rekeying by 
keeping the KEKi of the previous area GCKSj unchanged. However, the FEDRP 
approach suffers from systematic rekeying when the mobile member enters a new 

25 area GCKSi for the first time. That is, when the member MM|| moves to the new 

area GCKS^, its mobility is supported In the previous area GCKSr, but not in the 
visited area GCKSj. in addition, during the session duration, It is more probable 
that a member enters a given area for the first time than for more than one time. 
As a result, when a member moves between areas, it is highly probabfe that a 

30 iocai rekeying OGcurs in the visited area= 
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ft is desirable to provide a lightweight mechanism that optimizes the 
computation for mobile members while reducing the impact of their movement on 
group rekeying 

Summary of the invention 

5 The present invention provides a method of and apparatus for inter-area 

rekeying of encryption keys in secure mobile multicast communications as 
described in the accompanying claims. 

Brief description of the drawings 

is a schematic diagram of the architecture of a distributed group key 
10 management system, showing Traffic Encryption Key distribution 

is a schematic diagram of the group key management system of , showing 
inter-area movement of group members, 

is a schematic diagram of the group key management system of , showing a 
known rekeying method for inter-area movement of group members, 

15 is a schematic diagram of the group key management system of , showing 

another known rekeying method for inter-area movement of group members, 

is a schematic diagram of the group key management system of , showing 
yet another known rekeying method for inter-area movement of group members, 

is a schematic diagram of a group key management system of the kind 
20 shown and for inter-area movement of group members in accordance with one 
embodiment of the present invention, given by way of example, is a flow chart of 
an example of a rekeying process when a member joins an area in the system of , 

IS a flow chart of an example of a rekeying process when a member leaves 
an area in the system of , and 

25 



is a flow chart of an example of a traffic key reception process in the system 

of. 
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Detailed description of the preferred embodiments 

Embodiments of the present invention shown in Itie drawings enable a 
reduction in the computational capabilities needed for both the key server and area 
members to support encryption/decryption operations due to membership 
dynamism (group Join/leave) and member's frequent mobility, by separating 
member's mobility treatment from group membership dynamism, and by 
amortizing the movement impact over the TEK validity period. In addition 
embodiments of the present invention provide the following features. 

• Reduced impact of member's mobility on group rekeying: the key 
management system, by separating member*s mobility treatment from 
group membership dynamism (group join/leave), facilitates movement of 
mobile members between administrative areas while remaining {from a 
group membership viewpoint) in the group, in addition, when the mobile 
member leaves the group, the rekeying process reacts with a limited 
additional impact on the remaining group members. This residual impact is 
typically due to the accumulated information that the leaving mobile 
member got from the different areas it visited. 

• Reduced computational requirements for mobile members: mobile 
members have generally very limited resources (e.g. memory space, and 
computational power). Hence, it is useful to minimize for mobile members 
both the memory space requirements (e.g. number and size of stored keys) 
and computations (those involving cryptographic algorithms in particular), 

• Trust in Mobile members: the group key management system foresees a 
level of trust to attribute to mobile members because they may move across 
different managed areas, and accumulate information alx>ut local security 
services of the different areas they visit. In particular, for some applications, 
such as military communications, the mobile member must be prevented 
from continuing to hold valid keying material that it got from a specific 
security server when the mobile member is out of the management area of 
that server for more than a given period. 

Mora particularly, embodiments of the present invention provide the foitowing 
enhancements: 
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• avoiding rekeying the members of the visited area each time a mobile 
member enters It; 

• amortizing the impact of member's movement over the TEK lifetime; 

• providing a conditional self-generation of local keys for mobile members to 
5 reduce signalling between the iocal GCKS and Its members; 

• saving resource consumption using derived key-based rekeying for mobile 
group members. 

This mechanism enables the impact of member's movement on area 
member rekeying and that of the visited area in particular to be reduced 
10 significantly. It separates the rekeying of mobile members from membership 
dynamism (group join/leave) without affecting the KEK rekeying process. This is 
achieved by introducing a specific key called Visitor Encryption Key (VEK), which 
is provided to mobile members when they move to a new area. 

In more detail, as shown in Figure 6, when the mobile member MMii moves 
15 form areai to areaj, it sends a signalling message to GCKSi of the area it is leaving 
as well as a signalling message to GCKSj of the area in which it is arriving to notify 
them about its mobility. The signalling messages may be implemented as in 
FEDRP and IR, using credentials, for example as described in S. Griffin, B, 
DeCleene, L Dondeti, R. Flynn, D. Kiwior, and A. Olbert," Hierarchical Key 
20 Management for Mobile Multicast Members". Once MMj] is in the new area], the 
GCKSj sends the Visitor Encryption Key VEKj rather than the KEKj to the mobile 
member using a secure channel This key VEK| acts similarly to a KEK within this 
areaj but is not used by members MMj already in the areaj and possessing the 
current KEKj. 

25 There are two t/pes of owner lists for the GCKSs: EKOL (for example simitar 

to that described rn B, DeCieene, L.Dondeti, S. Griffin, T. Hardjono, D. Ktwior, J. 
Kurose, D. Towsfey, S. Vasudevan, and G, Zhang, "Secure Group 
Communications for Wireless Networks", Proceeding of Military Communications 
Conference, IEEE MiLCOM, Communications for Network-Centric Operations: 

30 Creating the information Force= Vienna, October 2001, pp= 113-117) and in 
addition a Visitor-Key Owner List VKOL' that distinguishes between group 
members MMj situated in the respective group key management area^ and group 
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members MM^ that were situated in the respective group key management areai 
areas but are visiting another area areaj. in this embodiment of the present 
invention, Visitor-Key Owner Lists (such as VKO!^) contain the list of members still 
holding a valid VEK (such as VEKj) but which have subsequently left the key area 
5 (areai) in which they obtained the VEK. It is within the scope of the present 
invention, however, to modify the system to function In other ways, for example so 
that the Visitor-Key Owner Lists (such as VKOLs) contain the list of members still 
holding a valid VEK (such as VEK) and which are still in the key area (areas) in 
which they obtained the VEK. This may assume that GCKSi can distinguish 
10 between members holding VEK and are out of area; from those that are in. For 
example, when the VKOL is reset (as described t)elow) only members with VEK 
and that are out of areai will be removed. 

The flow charts shown in Figures 7 to 9 show in more detail examples of the 
processes that the local GCKS performs in the embodiment of Figure 6 when a 
15 new member enters or leaves the area. The processes shown include Group join 
and leave, as well as movement of a current group member between two areas. 

In the embodiment of the invention shown in Figure 6, when a mobile 
member MMij moves intra-group from areai to areaj, the following processes will be 
triggered.: 

20 • if this mobile member MM^ holds a VEK, the GCKSi places the member in 
the VKOLi list. 

• if the mobile member MMij holds a KEK, the GCKSi places that member in 
the EKOLi list. 

in both cases, the GCKSi triggers a validity period (as In FEDRP) for the local 
25 key VEK, or KEKj that the mobile member MMy holds. Subsequently, sf the mobile 
member returns to areas during the validity period, the GCKSi removes this 
member from the list and no local rekeying occurs (optionally, GCKSs provides the 
entering member with the current TEK). Accordingly, it is unnecessary to rekey 
area members when a mobile member returns to a previously visited area. 
30 However, if the mobile member remains out of the areai and the period expires, 
the local GCKS. resets the owner list EKOL or VKOLi and distributes a new local 
key (KEKj or VEKi) to each concerned local member using a secure channel. 
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Once the mobile member MMy enters the area], we may distinguish two 
cases: 

# If there are no VEKj-members, the GCKSj generates a VEKj key (rather than 
a new KEKj) and sends it (optionafiy, along with the current TEK) to the 

5 visiting member MMi) in a secure channel, and the KEKj remains 

unchanged. 

• If VEK|-members exist, the GCKSj checks first whether the current VEKj 
was used to encrypt the previous TEK. If it is not the case, the GCKSj wiit 
provide the entering mobile member tsAM\\ the current VEK|. Otherwise, the 

10 GCKSi will provide the entering mobile member MMi| a new VEK| derived 

from the current value of VEKj (preferably using a one-way hash function, 
for instance: VEKMew=Hash(VEKcurrent)). During the validity period of the 
current TEK, the local GCKSj may not derive more than once a new VEKj 
value whatever the number of new mobile members that enter GCKSj's 

15 area] during the TEK validity period, since the visited GCKSj is unaware 

when the visiting mobile member MMy joined the group in a different area. 

Note that in ail cases, no local rekeying (KEKj or VEKj) is triggered whenever 
a mobile current group member MMjj moves between two areas. Besides, both 
Backward and Forward secrecies are ensured. Hence, this embodiment of the 
20 present invention separates fully member's intra-group mobility from group 
membership dynamism (group join/ leave). 

When a new member (as opposed to a current group member entering the 
area by intra-group mobility) joins the group via a given area; where there are 
VEK-members, the local GCKSj will distribute a new KEKj to all the area members 

25 encrypted separately with the current KEKj and the current VEK^ As a result, ail 

the currant area members will then hold the new KEK. The KEK^ is distributed by 
unicast to the new member' as ^e^^ using a secure channel. Next, the Domain 
GCKS mumcasts securely the new TEK to all the area GCKSs, Each area GCKS 
then multicasts the new TEK to all the group members using the locaf area keys 

30 (local KEKSs and locat VEKs when and where there are VEK»mambers). 

When any group member leaves the multicast group (as opposed to a 
current area member leaving the area by intra-group mobility), ail the area keys it 
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holds are changed within the affected areas. In this way, for a given areah the 
GCKSi sends either a new KEKj or a new VEKj (depending on which local key the 
leaving member holds) to the concerned members of Hie area^ using a secure 
channel with each member, which may be any secure channel except that based 
5 on the compromised encryption key (current VEK/KEK), for example a unicast 
channel. Next, the Domain GCKS muiticasts securely the new TEK to aH the area 
GCKSs. Each area GCKS then muiticasts the new TEK to all the group members 
using the local area keys (local KEKs, and local VEKs when and where there are 
VEK-members) In circumstances where it is desired for a mobile member to be 
10 able to change multicast address while keeping the same Traffic Encryption Key 
TEK, it is unnecessary to send the mobile member a new TEK or to rekey the 
TEK. 

If the rekey Is a KEKi rekey, all the local members will be sent the new KEKi 
and the local VKOL list is reset (previous members who visited the area^ are 
15 absent will no longer hold a valid VEKi); in this case, any group members stilt in 
the areai that hold a VEKi will switch to the new KEKi. Once in place, the local 
GCKSj distributes the new TEK in one multicast transmission using the local keys. 

However there is no need to change the KEK^s of the areaj if the leaving 
member held only the VEf^. Hence, we save resource consumption since the local 

20 KEKi remains unchanged. In fact, in prior art approaches, when a member leaves 
the group session, a new local KEK is distributed individually for each remaining 
area member before a new TEK is multicast to the^ members. For some 
applications, the multicast traffic is interrupted until the new TEK will be distributed. 
This may increase session interruption latency particularly when the number of 

25 remaining area members is important. With this embodiment of the present 
invention, when the member leaving areai holds a VEK^ and not a KEK, the 
session interruption latency is significantiy reduced whether or not the number of 
KEKi-members in the affected areai is significant. Such a gain of processing time is 
particularly valuable in real-time applications. 

30 For both group join and leave cases, the EKOU as wall as the VKOU fists on 

which the leaving member Is listed are reset when the new local key is distributed 
to areai members. 
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In summary, in this embodiment of the present invention, the VEKi can be 
considered as a temporary key, since the members holding such a key in a given 
area will switch to the new KEKi when a KEKi rekeying occurs (after a group join or 
periodic rekeying). Any additional processing that management of the VEKi may 
5 introduce in the GCKSt is negligible. 

It is within the scope of the present invention, however, to modify the system 
to function in other ways with respect to VEK management, for example, so that a 
new member receives an updated VEK rather than an updated KEK, Another 
modification would suggest that when a member holding a VEKi leaves the group, 

10 the GCKSi may distribute a new KEKj (rather than updating VEK* as described in 
our basic mechanism) for all the remaining areai members using a secure channel 
with each of those members. Similarly, when a member leaves the group via areai 
while holding a KEKi, GCKSi may securely unicast a new KEKi for KEKpmembers 
only, and VEKr remains unchanged for VEKrmembers. in this case, VKOLi list will 

15 not be reset. In another option, when a member joins the group via areai, GCKSi 
may multicast a new KEKj encrypted with KEKi only, and VEKi remains unchanged 
for VEKj-members. \n this case, VKOLj list will not be reset. 

Each time the local GCKSj needs to forward a new TEK (TEK rekey) within 
its areai that includes VEKrmembers, it muiticasts the new TEK separately 
20 encrypted with KEKi and VEKi. To achieve this, the local GCKSj checks first if it 
has obtained the current VEI^ by derivation from the previous one since the 
previous TEK fonA^arding. 

If so, the local GCKSi notifies the VEKrmembers (within the TEK distribution 

message) that the new TEK they are receiving is encrypted with a new VEK^ 

25 (denved from the previous one see above). The VEKrmembers then decrypt this 
new '^£> / .-"A VEK| (the members obtain the new VEKi by applying 

the same function to the previous VEKj as the one that was applied by the GCKSi 
server), 

ff no derived VEK vaiue has been generated since the previous TEK 
30 forwarding, it means that the VEKi has not been changed since then= Thus, the 
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GCKSi encrypts the TEK. with the current value of the VEKi and multicast it to 

VEKj-members, notifying them not to obtain a deriveci VEKj. 



